Closed
Bug 87472
Opened 24 years ago
Closed 24 years ago
memory from closed windows not freed until shutdown
Categories
(SeaMonkey :: General, defect, P1)
Tracking
(Not tracked)
RESOLVED
INVALID
mozilla0.9.3
People
(Reporter: dbaron, Assigned: dbaron)
Details
(Keywords: memory-leak, top-memory-leak)
Attachments
(2 files)
In bug 84136, I wrote:
| However, even with that patch, if I start mozilla (debug), I see 42MB memory
| usage, and if I open 6 more windows I see memory usage go up to 52MB, and it
| doesn't come back down when I close those Windows. However, according to our
| leak detection tools we are freeing the memory before we exit. So what I'm
| seeing is probably the hardest type of leak to diagnose -- one where we free
| memory later than we should have, but do free it. (It's hard for a leak
| detection tool to know when something *should* have been freed and detect that
| it was freed later than it should have been. Many objects are supposed to be
| very short-lived and some are supposed to exist for the entire lifetime of the
| program.) Anyway, I'll look into it a bit more...
I did the following test in both a debug and opt build:
* start mozilla
* click my default profile in the profile manager
* open 6 new windows by hitting Ctrl-N in the newest window
* close the windows by clicking the X in the corner in the reverse order they
were opened
In my debug build I saw memory use increase (based on top) from about 42M to
52M, and not fall after I closed all but the last window. In my opt build, I
saw the same, except the numbers were 22M and 30M. (All on Linux.)
When I used about:bloat?clear in the first window, then opened the windows, and
then used about:bloat in that window at the end, I saw the differences in memory
use that I'll attach. (Note that objects logged by nsTraceRefcnt probably
account for something like 20% of our heap.) When I did the same thing except
loading about:bloat in place of about:bloat?clear, I saw very few leaks logged
by nsTraceRefcnt after the app shut down. (They had to be separate runs because
about:blank?clear messes up the stats.) I'll attach both runs to the bug.
Assignee | ||
Updated•24 years ago
|
Assignee | ||
Comment 1•24 years ago
|
||
Assignee | ||
Comment 2•24 years ago
|
||
Assignee | ||
Comment 3•24 years ago
|
||
OK, I fell into the "top" trap from the other bug. I think what I was seeing
was more fragmentation and such than anything else -- when I reopened the 6
windows again memory use didn't increase significantly.
I suspect my "memory change" stats may have changed a bit if I'd opened and
closed a new window before doing the clear or if I'd used open web location
before doing the clear. However, typing in the URL bar and even sometimes open
web location are so totally broken right now that I can't tell.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
Updated•21 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•